Slip-box

To be fleeting notes

Fleeting

To be literature notes (Understanding)

L-Origin

设计考试生存指南：资深设计师实战指南

引言：现代游戏设计师面临的严峻挑战

欢迎。如果您立志从事游戏设计行业，很快就会遇到业内最具挑战性的新筛选机制之一：设计测试。这是现代招聘中的一种新趋势，尤其对于那些收到大量申请的大公司而言更是如此。设计测试存在的意义是什么？因为它可以作为一种“天然筛选器”，筛选出真正有热情的申请者，而且对于公司来说，它也是一种“成本低廉且便捷”的方式，可以进行一对一的比较，从而节省时间。

我叫彼得·布查，在Playdead（《地狱边境》、《Inside》）和Studio Gobo等工作室拥有超过十年的工作经验，经历过不少类似的考验。本指南并非旨在提供“完美”答案，而是分享我从经验中汲取的宝贵教训，帮助你为接下来的_过程做好准备_——包括繁重的工作量、心理上的挑战以及常常令人沮丧的结果。不妨将此视为一份实战指南，助你顺利开启这段冒险之旅。

第一课：解读简报并明确你的答案

1.1 开放式形式的困境

你面临的首要挑战之一就是模糊或开放式的测试要求。许多测试会给出类似“只要易于审核，你想做什么都可以”这样的指示。这是因为公司测试的内容往往不仅仅局限于你声明的专业领域。例如，关卡设计测试可能还会要求你设计敌人、机制和谜题，这就要求你是一位敏捷的设计师， 并且对游戏开发有广泛的了解。

这就带来了一个难题：是撰写一份内容详尽、篇幅较长的文档，但可能让人感到信息过载，还是提交一份简洁明了、但可能显得不够完整的方案？作为设计师，你既不想“用大段文字吓到或让任何人感到厌烦”，也需要确保你的想法能够被充分理解。解决这个难题是成功提交方案的第一步。

1.2 案例研究：两种不同的方法

你如何选择答案格式，很大程度上反映了你作为设计师的风格。以下是我收到的两份格式要求模糊的测试题，对比了不同的格式方法如何导致了不同的结果。

1.3. 您的格式化战略检查清单

根据这些经验，这里有一份实用的清单，可以帮助你有效地组织答案。

1.先通读整个测试：这听起来很简单，但却是最常见的错误。在开始设计 之前， 你必须理解任务的所有部分，以免为时过晚才发现关键需求。

2.进行“情境分析”： 这是一个强大的设计工具。研究该公司之前的游戏，了解他们的设计理念。分析你的功能或任务将要存在的具体情境——围绕它有哪些机制、叙事节奏或玩家工具？这可以确保你的设计“符合他们的思维方式”。

3.寻求第二意见： 请一位朋友——尤其是一位语法眼光好的朋友——帮你审阅作品。旁观者清，可以发现你忽略的措辞含糊或论证薄弱之处。

4.展示，而非仅仅描述： 一大段文字会让人感到疲惫。使用图表、简单的模型、流程图和图片，使复杂的概念易于理解，并以可视化的方式展示你的沟通技巧。

但构建完美的答案仅仅是成功的一半。另一半是与时间的残酷较量，庞大的工作量本身就是一项考验。

第二课：工作量的马拉松以及何时应该抽身而出

2.1 时钟的现实

大多数设计测试的时间安排都很紧凑，通常只有 4 到 10 天。如果你是学生或者有全职工作，这可能会让你感到压力巨大。你可能每天晚上只能挤出几个小时，而其他候选人却要投入十个小时。

我曾经面临过一种“幸福的烦恼”：同时收到两份试卷——一份截止日期是48小时，另一份截止日期是7天——而且我必须同时完成。压力巨大，有时工作量实在太大。

2.2 案例研究：让设计师崩溃的测试

以下是我最终放弃的一个角色扮演游戏制作系统测试中的警示故事。它说明了测试可能会出现哪些问题，以及为什么有时放弃才是正确的选择。

•错误： 我没有做好功课。我直接开始研究制作系统并构思设计方案，而没有先 调查所需的实现工具。后来我才发现，指定的免费 Unity UI 工具“已经过时且存在一些问题”。

•顿悟： 很明显，用这个有问题的工具实现我的设计“几乎不可能”。我连自己设定的质量标准都达不到，更别提测试中列出的那些繁多的功能需求和额外目标了。

•决定： 比赛还剩三天时，我感到彻底失败。我“扔毛巾认输”，决定不再提交。

2.3. 关于工作量最重要的教训

当时，那个决定让我觉得自己很失败。但现在回想起来，我觉得那次测试本身或许是一种不同的挑战：它考察的是“在面临极高要求的情况下，我会如何应对”。也许，测试的目的不仅仅是考察谁能完成工作，更在于考察谁能识别出看似不可能完成的任务，并做出专业的应对。

这里最关键的教训是，公司有时会不加考虑地给应聘者布置这些测试，而忽略了测试带来的工作量。如果你也遇到类似的情况，请记住：“放弃一些测试是可以的。” 如果某个测试让你觉得难到无法完成，或者与你的技能不符，你并不孤单。

漫长的工作之后，往往是漫长的等待。倾注心血完成作品之后，最后的考验是熬过随之而来的漫长等待。

第三课：寂静之声与寻求反馈

3.1. 将你的期望值设为零

残酷的现实是：即使你花费数天甚至数周的时间完成设计测试，最有可能的结果也是一无所获。公司利用这些测试作为一种廉价的筛选手段来节省资源。一旦你被筛选掉，你就不再是他们的优先考虑对象。所以，当你点击“发送”按钮时，为你的成果感到自豪，但也要做好杳无音信的准备。

3.2. 一系列令人失望的反馈

当你收到回复时，它往往会落入以下几种令人沮丧的类别之一。以下是我收到的一些真实反馈示例，从毫无用处到出人意料的宝贵信息，应有尽有。

•千篇一律的拒绝： 含糊不清、毫无帮助，而且完全不带个人色彩。它没有提供任何关于你被拒绝原因的信息。

•流程失败： 这种反馈表明，公司在安排测试_之前没有检查基本资格（例如您的签证状态），从而浪费了您的时间。_

• “好”但严厉的反馈： 虽然可能会让人难受，但这却是最好的情况。这种反馈简明扼要、直接有力，而且极具批判性，能让你真正从中学习。

3.3. 你的提问权

虽然现实情况往往是得不到反馈，但你不应该默默接受。你投入了大量的时间和精力，理应了解结果。我的建议是，你_应该“主动询问”。_ 如果每位求职者都能礼貌而坚定地争取建设性的反馈，或许就能促使公司更加尊重求职者，并改进招聘流程，造福所有人。

4. 总结要点：您的设计测试生存工具包

设计测试是现代招聘环境中令人望而生畏的一部分，但并非不可战胜。只要了解流程、合理分配精力并设定切合实际的预期，就能将其转化为宝贵的学习经验。以下是对最关键经验的总结。

1.成为一名敏捷设计师： 做好准备迎接超出你专业领域的测试。关卡设计测试可能会要求你设计敌人，游戏设计测试可能会包含技术脚本编写方面的挑战。

2.先做好功课：在开始设计之前，务必阅读、理解并考虑_整个_测试。这个简单的步骤可以避免你日后犯下重大错误。

3.合理安排时间： 要意识到这些测试需要投入大量时间。做好相应的计划，并且不要害怕申请延期——公司通常会理解，尤其是在他们知道你在收到测试之前就已经和他们达成了合作协议的情况下。

4.展现你的个性： 测试不仅仅是回答对错问题。把它当作一个机会，来展示你独特的设计思维、沟通风格和分析问题的能力。

5.做好万全准备： 付出大量努力，甚至可能要重复多次，而且不求任何回报。这可能是一个令人沮丧、吃力不讨好的过程。但最重要的是，不要放弃。

Surviving the Design Test: A Senior Designer's Field Guide

Introduction: The Modern Gauntlet for Game Designers

Welcome. If you're aiming for a career in game design, you'll soon encounter one of the industry's most challenging new filters: the design test. This is a new tendency in modern recruitment, especially for major companies flooded with applications. Why do they exist? Because they serve as a "natural filter," weeding out all but the most dedicated applicants, and they are a "cheap and easy way" for companies to create a one-to-one comparison that saves them time.

My name is Peter Bucha, and with over 10 years of experience at studios like Playdead (Limbo, Inside) and Studio Gobo, I've faced my share of these tests. This guide isn't about giving you the "perfect" answers. Instead, its purpose is to share the hard-won lessons from my experience to prepare you for the process—the demanding workload, the psychological hurdles, and the often-frustrating outcomes. Think of this as a field guide to help you navigate the adventure ahead.

1. Lesson One: Decoding the Brief and Defining Your Answer

1.1. The Dilemma of the Open-Ended Format

One of the first challenges you'll face is the vague or open-ended brief. Many tests give instructions like, "do anything you want as long as it's easily reviewed." This is because companies often test for more than just your stated specialty. A level design test might also require you to design enemies, mechanics, and puzzles, demanding you be an agile designer with a broad understanding of game development.

This creates a difficult choice: do you create a comprehensive, multi-page document that risks being overwhelming, or do you deliver a concise pitch that might seem incomplete? As a designer, you don't want to "intimidate or bore anybody with walls of text," but you also need to ensure your ideas are fully understood. Navigating this dilemma is the first step toward a successful submission.

1.2. Case Studies: Two Different Approaches

How you decide to format your answer says a lot about you as a designer. Here’s a comparison of two tests I received that had vague format requirements, and how different approaches led to different outcomes.

1.3. Your Strategic Checklist for Formatting

Based on these experiences, here is a practical checklist to help you structure your answer effectively.

1. Read the Entire Test First: This sounds simple, but it's the most common mistake. You must understand all parts of the assignment before you start designing to avoid realizing a critical requirement too late.
2. Conduct a "Context Analysis": This is a powerful design tool. Research the company's previous games to understand their design philosophy. Analyze the specific context where your feature or mission will exist—what mechanics, narrative beats, or player tools surround it? This ensures your design "fits within their way of thinking."
3. Seek a Second Opinion: Ask a friend—especially one with a good eye for grammar—to review your work. Fresh eyes can spot unclear phrasing or weaknesses in your argument that you've missed.
4. Show, Don't Just Tell: A wall of text is fatiguing. Use diagrams, simple mockups, flowcharts, and images to make complex ideas digestible and to demonstrate your communication skills visually.

But structuring the perfect answer is only half the battle. The other half is a brutal fight against the clock, where the sheer volume of work can become a test in itself.

2. Lesson Two: The Marathon of Workload and When to Walk Away

2.1. The Reality of the Clock

Most design tests operate on aggressive timelines, typically between 4 and 10 days. If you're a student or have a full-time job, this can feel overwhelming. You might only be able to squeeze in a few hours each night while other candidates dedicate ten hours a day.

I once faced the "luxury problem" of receiving two tests at once—one with a 48-hour deadline and another with a 7-day deadline—that I had to complete simultaneously. The pressure can be immense, and sometimes, the workload is simply too much.

2.2. Case Study: The Test That Broke a Designer

Here is a cautionary tale from an RPG crafting system test that I ultimately gave up on. It illustrates how a test can go wrong and why walking away is sometimes the right decision.

• The Mistake: I didn't do my homework. I jumped straight into researching crafting systems and developing a design idea before investigating the required implementation tool. I only later discovered that the specified free Unity UI tool was "deprecated and a bit broken."
• The Realization: It became clear it would be "near impossible" to implement my design with the broken tool. I couldn't deliver something that met my own quality standards, let alone the extensive feature requirements and bonus goals listed in the test.
• The Decision: With three days left on the clock, I felt defeated. I "threw the towel in the ring" and decided not to submit anything.

2.3. The Most Important Lesson on Workload

At the time, that decision left me feeling like a failure. But retrospectively, I've considered that the test itself might have been a different kind of challenge: a test of "how I would react in a situation where there were exceptional high requirements." It's possible the goal wasn't just to see who could complete the work, but who could recognize an impossible situation and respond professionally.

The key lesson here is that companies sometimes throw these tests at applicants without much consideration for the workload involved. If you find yourself in a similar situation, remember this: "it's okay to let go and give up on some of them." If a test feels impossibly difficult or a poor fit for your skills, you are "not alone" in feeling that way.

The marathon of work is often followed by a marathon of waiting. After pouring your heart and soul into a submission, the final test is managing the silence that comes next.

3. Lesson Three: The Sound of Silence and the Quest for Feedback

3.1. Set Your Expectations to Zero

Here is the harsh reality: after spending days or even weeks of your life on a design test, the most likely outcome is to receive absolutely nothing. Companies use these tests as a cheap filter to save their own resources. Once you've been filtered out, you're no longer their priority. So, when you hit "send," be proud of your work, but be prepared for silence.

3.2. A Spectrum of Disappointing Feedback

When you do get a response, it often falls into one of several frustrating categories. Here are real examples of feedback I've received, from the useless to the surprisingly valuable.

• The Generic Rejection: Vague, unhelpful, and completely impersonal. It provides no insight into why you were rejected.
• The Process Failure: This is feedback that reveals the company wasted your time by failing to check basic qualifications—like your visa status—before assigning the test.
• The "Good" but Harsh Feedback: While it might sting, this is the best-case scenario. It's brief, direct, and critical feedback that you can actually learn from.

3.3. Your Right to Ask

While the reality is often no feedback, you shouldn't accept it silently. You invested significant time and effort, and you have a right to understand the outcome. My advice is that you "should try to ask for it." If every candidate politely but firmly pushes for constructive feedback, it may encourage companies to treat applicants with more respect and improve their hiring process for everyone.

4. Final Takeaways: Your Design Test Survival Kit

Design tests are a daunting part of the modern hiring landscape, but they are not unbeatable. By understanding the process, managing your effort, and setting realistic expectations, you can turn them into a valuable learning experience. Here is a final summary of the most critical lessons.

1. Be an Agile Designer: Be prepared for tests that stretch beyond your specific specialty. A level design test might ask you to design enemies, and a game design test might include a technical scripting challenge.
2. Do Your Homework First: Always read, understand, and consider the entire test before you begin designing. This simple step will save you from critical mistakes down the line.
3. Manage Your Time Wisely: Recognize that these tests are a significant time commitment. Plan accordingly, and don't be afraid to ask for an extension—companies are often understanding, especially if they know that the engagement was something you had before you even received the test.
4. Showcase Who You Are: The test is more than just a right or wrong answer. Use it as an opportunity to demonstrate your unique design thinking, your communication style, and your ability to analyze context.
5. Prepare for Anything: Do a lot of work, potentially multiple times, and expect nothing in return. It can be a frustrating, thankless process. But above all, don't give up.

L-My Words

L-Zotero citation key

https://www.youtube.com/watch?v=KSVzg6SEs48
https://drive.google.com/file/d/1xnaow0DuuexzSjunSWi07_0vvyJcc_aD/view

To be permanent notes (Complete Ideas)

P-Self Explained Sentences

P-Connection

• relations or differences with other knowledge - 与其他知识的联系或区别
• Parent
  • Caused by::
    -
  • Driven by::
    -
  • Cite from::
    -
• Child
  • Excalidraw::
    -
  • Is source of::
    -
  • Including::
    -
  • Have Example::
    -
  • Contributes to::
    -
  • Consist of::
    -
• Friend
  • Left
    • Achieved with::
      -
    • Affected by::
      -
    • Supported by::
      -
    • Enhanced by::
      -
    • related::
      -
  • Right
    • against::
      -
    • Opposites::
      -

P-SlipBox

• 将笔记放入对应卡片盒

• 添加双链